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Abstract —In pervasive computing environments, various entities often have to cooperate and integrate seamlessly in a 
situation which can, thus, be considered as an amalgamation of the context of several entities interacting and coordinating 
with each other, and often performing one or more activities. However, none of the existing context models and ontologies 
address situation modeling. In this paper, we describe the design, structure and implementation of a generic, flexible 
and extensible context ontology called Rover Context Model Ontology (RoCoMO) for context and situation modeling 
in pervasive computing systems and environments. We highlight several limitations of the existing context models and 
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limitations in our approach. We also illustrate the applicability and utility of RoCoMO using a practical and extensive 
case study. 
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1 Introduction 

Recent years have witnessed rapid advances 
in enabling technologies for pervasive comput¬ 
ing environments - an important step being 
context-awareness in systems. Dey and Abowd 
IflTl describe a context-aware system as one that 
"uses context to provide relevant information 
and/or services to the user, where relevancy 
depends on the user's task." Context aware¬ 
ness enables a new class of applications in 
pervasive computing that can help users navi¬ 
gate through unfamiliar territory, find preferred 
restaurants nearby, receive messages in the least 
obtrusive manner, get extra sleep when meet¬ 
ings are canceled, find people with similar in¬ 
terests, and so on. The use of context informa¬ 
tion in these applications reduces the amount of 
human effort and attention that an application 
needs to service the user's requests. 

Moreover, in pervasive computing environ¬ 
ments, various entities often have to cooper¬ 
ate and integrate seamlessly in a Situation to 
achieve a common objective. Thus, Situation 
Awareness can be defined as "the capability 
of the entities in pervasive computing environ¬ 
ments to be aware of situation changes and au¬ 
tomatically adapt themselves to such changes 
to satisfy user requirements, including security 
and privacy." and a Situation can be described 
as "a set of contexts in the application over a 


period of time that affects future system behav¬ 
ior." 0. A situation can be considered as an 
amalgamation of the context of several entities 
interacting and coordinating with each other, 
and often performing one or more activities. 

The context model forms the underlying 
framework for modeling and representing con¬ 
text in the pervasive computing environment 
and context-aware systems. To support context- 
and situation-awareness, and adaptation of the 
entities in pervasive computing environments, 
it is necessary to model and specify context and 
situations in a suitable way such that the con¬ 
textual information can be easily exchanged, 
shared and reused. As discussed in several 
papers including Chen et al. H and Krish¬ 
namoorthy et al. |H, ontologies are a powerful 
tool for modeling context and the encompass¬ 
ing situations in context-aware systems because 
they promote knowledge sharing and reuse 
across different applications and services inter¬ 
acting in a pervasive computing environment, 
thus, enhancing their interoperability. They al¬ 
low context-aware systems to use existing logic 
reasoning mechanisms to deduce high-level, 
conceptual context from low-level, raw context, 
and handle uncertainty and inconsistency in 
context. They can be combined to form a more 
complex ontology and save the effort. 

However, none of the existing context models 
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and ontologies address situation modeling in 
a dynamic environment where the situation 
constantly evolves. To address this limitation, 
we described the design of a general and intel¬ 
ligent context-aware middleware called Rover 
II and its general, flexible and extensible con¬ 
text model for context and situation model¬ 
ing, called Rover Context Model (RoCoM), in 
Krishnamoorthy et al. f4j and Bhargava et al. 
lEl . RoCoM has four Primitives - Entity, Event, 
Activity and Relationship. These Primitives are 
the building blocks of every context-aware sys¬ 
tem or middleware built using this model. Axiy 
piece of contextual information in the system 
can be attached to one of these primitives and 
any situation can be modeled via them. 

We introduced the Rover Context Model On¬ 
tology (RoCoMO), which is the underlying on¬ 
tology for RoCoM and is currently deployed 
and implemented in Rover II, in 0. In this pa¬ 
per, we describe its design, structure and imple¬ 
mentation in detail. Each primitive of RoCoM 
corresponds to a top level concept in RoCoMO 
from which other concepts are derived. Our 
main contributions in this paper are: 

• Elighlighting several shortcomings of 
other existing standard models and on¬ 
tologies for context and situation mod¬ 
eling and demonstrating the utility of 
RoCoMO's capabilities that address those 
shortcomings, 

• Illustrating the benefits, applicability and 
utility of RoCoMO, as opposed to other 
existing models and ontologies, using a 
simple and practical case study for con¬ 
text and situation modeling in pervasive 
computing environments. 

The rest of this paper is organized as fol¬ 
lows. In Section [2 we describe a case study 
which we use in this paper to motivate and 
illustrate the benefits and utility of RoCoMO. 
We briefly discuss the existing approaches to 
context and situation modeling, and highlight 
their limitations in Section |3] In Section [4}. we 
explain the design and implementation of Ro¬ 
CoMO and how it addresses several limitations 
of contemporary approaches such as lack of 
provision for provenance, quality of context, 
multiple representations of contextual informa¬ 
tion as well as support for security etc. We 
illustrate the benefits of RoCoMO by revisiting 
the case study in Section [6j We conclude and 
outline future work in Section [7} 


2 Motivation 

We describe a simple but practical case study 
here in order to motivate and illustrate the var¬ 
ied nature of context, and the capabilities that 
context models and ontologies should possess 
for representing and modeling this situation 
in real time pervasive computing systems and 
environments. We will return to this case study 
in Sections [5] and |6] to illustrate RoCoMO's 
modeling capabilities. For illustration, we have 
selected a situation from the domain of rescue 
and evacuation but this, by no means, restricts 
RoCoMO's applicability and generality. 

Afire incident takes place in a room on the fourth 
floor of a building on a university campus. Fire 
fighters and responders are using a context-aware 
system to coordinate the rescue efforts. A responder, 
using the system, gets updated readings from two 
temperature sensors in the room on fire. Using this 
contextual information, the system determines the 
time that responders have to evacuate the building 
before the whole building is engulfed in flames. The 
temperature information also has a quality measure 
attached to it to convey any inaccurate or incomplete 
information. Another responder is accessing the sys¬ 
tem to get confidential floor maps of the building and 
also determine the evacuation route people should 
take based on the floormaps and the time remaining. 

Representing and modeling this situation in a 
context-aware system (such as Rover II), using 
the existing ontologies, is not trivial. It involves 
interaction between several entities such as re¬ 
sponders which perform one or more activities. 
The entire situation is catalyzed by an event 
like the fire incident and the goal of the situa¬ 
tion is to evacuate the building. Each activity, 
whether being performed by the system or an 
entity, is driven by the goal or a sub-goal. 
Some of the activities can occur simultaneously, 
for instance, calculating the time remaining for 
evacuation and accessing the floor maps of 
the building. Other activities need to be per¬ 
formed sequentially - the evacuation routes can 
be determined only when the floor maps are 
available. The room has contextual information, 
that needs to be modeled and represented, 
such as the temperature readings of the room. 
To avoid ambiguity, the information must be 
clearly marked with its source (which sensor it 
is coming from) as well as the encoding format 
(whether it is in Celsius or Fahrenheit). This 
requires support for encoding format as well 
as provenance. The model should also support 
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attachment of quality attributes to contextual 
information such as probability or certainty 
Also, since the readings are getting updated at a 
fixed time interval, they should be timestamped 
to help determine the most recent reading. 
Another aspect of the system is security - only 
authorized personnel such as responders have 
access to the floor maps of the building. All 
these requirements call for a deeper under¬ 
standing of modeling situations. 

3 Related Work in Context and 
Situation Modeling 

We briefly describe some of the existing context 
models and their underlying ontologies in this 
section, and examine their limitations. 

CoBrA-OntH6l is a collection of ontologies for 
describing places, agents and events and their 
associated properties in an intelligent meeting- 
room domain. SOUPA ||3| was developed to 
provide pervasive computing developers with 
a shared and upper ontology that combines 
many useful vocabularies from different con¬ 
sensus ontologies such as FOAF, DAML-Time, 
RCC, BDI, and Rei policy ontology. A full list 
of these well known ontologies can be found at 
10 - 

Other contemporary ontologies include 
CONON[8] where the context ontologies are 
divided into upper ontology and domain- 
specific ontologies; CoDAMoS |j9| where the 
context ontology is centered around four 
entities - user, environment, platform and 
service; ASC/CoOL UTOl that enables context 
awareness and interoperability; Gaia lUDl that 
incorporates ontologies for context awareness, 
service discovery and matchmaking, and 
interoperation between entities in a pervasive 
computing infrastructure mainly geared 
towards smart spaces; and GLOSS ||T2| 
which employs ontologies for the precise 
understanding of various contexts and services 
in smart spaces. 

Several surveys such as those by Reichle et 
al. ( II5B , Krummenacher et al. |fl4f and Bettini 
et al. m) have asserted that, of all the current 
ontologies used for context modeling, SOUPA 
is the most comprehensive ontology. However, 
both SOUPA and CoBrA-Ont have no provision 
for provenance, quality of context and multiple 
representations. CONON enables provenance 
by using the concept of sensed, derived, ag¬ 
gregated or deduced context but lacks features 


like comparability. Gaia takes on the challenge 
of modeling uncertainty and reasoning over 
it. However, their ontologies are restricted to 
the smart spaces domain. They do not model 
provenance either. A more detailed evaluation 
of all these ontologies can be found in the 
surveys mentioned. 

Moreover, a major shortcoming of general 
and exhaustive ontologies such as OpenCyc 
|H6| is that they become too cumbersome to 
use in a system that is designed to be used 
efficiently and effectively in real time. Also, it 
is not possible for a small group of people to 
enumerate all the possible concepts and rela¬ 
tionships between them that could be used in 
a practical mobile or desktop application or 
system. Hence, in our opinion, it is better to de¬ 
velop the base ontology and make it extensible 
for users just as most of the previous context 
models and ontologies have done. Our goal in 
this paper is to follow a similar approach and 
go one step further by addressing all the limi¬ 
tations that these existing ontologies posses. 

We do not find much work in the literature 
where context-aware systems are extensively 
married to situational modeling. For modeling 
a situation (such as the Fire Incident mentioned 
earlier), none of the existing ontologies is ade¬ 
quate. This is mainly because these situations 
are rich and include events, which set a goal 
for the context-aware system to achieve, as well 
as entities interacting and performing a number 
of activities, along with their associated context. 
Moreover, a number of them have no provision 
for provenance, encoding bias and quality of 
context, and are often restricted to a single 
domain of use such as smart spaces. 

To address all these shortcomings, RoCoMO 
has been designed with an extensive ontologi¬ 
cal model-driven foundation along with capa¬ 
bilities to model both context and situation in 
a coherent and cohesive fashion. 


4 Structure, Design and Imple¬ 
mentation of RoCoMO 

Figure |l] shows how a situation can be repre¬ 
sented in terms of the different concepts of Ro¬ 
CoMO - entities, events, activities and relation¬ 
ships. Each of them has contextual information 
associated with it such as location, identity etc. 

At time t 0 , the Event catalyzes the context- 
aware system and sets the Goal for it. To achieve 
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Fig. 1: Interaction between the primitives 


the goal, different Entities - Entityl and Entity2 
perform a sequence of Activities, such as Activ¬ 
ity 1 and Activity2 beginning at time t|. Every 
activity is driven by its own goal - which can 
be the overall goal that is set by the event, as 
in case of Activity4, or a sub-goal, as in case 
of Activityl. Every activity has a start time, an 
end time and a duration associated with it (as 
shown on the Time scale). It has a pre-condition 
and a post-condition which are goal(s) that 
should have been met before the activity starts 
and once the activity ends respectively. For 
instance, Activity3 starts at time t 2 , when both 
SubGoall and SubGoal2 have been met, and 
ends at time t 3 , when its own goal, SubGoal3, 
has been met. The duration for this activity 
is t 3 - t 2 . An activity can be atomic and non- 
interruptable. 

RoCoMO has been developed in OWL2 DL 
and has two components: 

1) RoCoM Core Ontology which is divided 
into two upper level ontologies: 

• RoCoM Domain ontology - This on¬ 
tology includes concepts that char¬ 
acterize the knowledge of the do¬ 
main i.e. the primitives Entities and 
Events, along with concepts that 
represent Location and Time. Ex¬ 
amples of entities include persons. 


devices etc. while events can range 
from a simple service request to a 
road accident. 

• RoCoM Task ontology - This ontol¬ 
ogy characterizes the problem solv¬ 
ing structure of the domain and 
provides primitives for describing 
the problem solving process i.e. Ac¬ 
tivities as well as their Goals. Ex¬ 
amples of Activities include Calling, 
Scheduling etc. 

2) RoCoM Application Ontology which has 
concepts that extend the core ontology 
concepts and are specific to an applica¬ 
tion. 

Figure [2] shows a partial view of the Ro¬ 
CoM Core and Application Ontologies. The 
classes representing the primitives such as 'en¬ 
tity', 'event' and 'activity', along with 'loca¬ 
tion', 'time' and 'goal' are derived from the 
default OWL class 'Thing' and form the top 
level classes in the RoCoM Core Ontology. 
Each of the classes derived from these top 
level classes represents a different, unique and 
unambiguous concept in the ontology. For in¬ 
stance, 'physicalentity' is derived from 'entity' 
and can be used to denote any entity that has 
a physical or logical form. It has more specific 
derived classes such as 'person', 'device' or 'or- 
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Fig. 2: Partial view of The RoCoM Ontology Version 1.0 


ganization'. The fourth primitive 'relationship' 
can be represented in OWL in many ways: 
between two classes (as a subclass/superclass), 
a class and an individual (as a member) or a 
specific relationship between two individuals 
(as object properties). The context of any ele¬ 
ment - entity, event or activity is represented 
using datatype properties in OWL. 

The following shows an OWL code snippet 
for the description of an individual instance 
named "xyz" of class 'person' which has a 
relationship with another entity (represented 
by the object property termed 'daughter') and 
contextual information such as food preference 
(represented by the datatype property termed 
'likesfood'). 

(Class rdf:about="&person;person") 

( rdfs:label xml:lang="en")person(/rdfs:label) 

(rdfs:subClassOf rdf:resource="http:/ /mind7.cs.umd.edu:8134/Rover/ 
physicalentity#physicalentity" /) 

(/Class) 

(ObjectProperty rdf:about="&person;daughter") 

(rdf: type rdf:resource= " &owl;FunctionalProperty" /) 

(rdf:type rdf:resource="&owl;InverseFunctionalProperty"/) 

(rdfs:label xml:lang="en") daughter(/rdfs:label) 

(rdfs:subPropertyOf rdf:resource="&person;contact"/) 

(inverseOf rdf:resource="&person;father"/) 

(inverseOf rdf:resource="&person;mother"/) 

(/ObjectProperty) 

(DatatypeProperty rdf:about="&person;likesfood") 

(rdfsdabel xml:lang="en") likesfood (/rdfsdabel) 

(rdfs:subPropertyOf rdf:resource="&person;likes"/) 

(/ DatatypeProperty) 

(Namedlndividual rdf:about="&person;xyz") 

(rdf: type rdf:resource=" &person;person" /) 

(rdfsdabel xml:lang="en")xyz (/rdfsdabel) 

(persondikesfood rdf:datatype="&xsd;string")indian(/person:likesfood) 

(/Namedlndividual) 

The core ontology can be further extended to 


concepts specific to an application, such as M- 
Urgency [17f , to form a part of the Application 
Ontology. M-Urgency is a public safety appli¬ 
cation that enables mobile users to stream live 
video from their devices to local PSAP (Public 
Safety Answering Point) along with the audio 
stream, the real time location information and 
any personal and relevant information about 
the caller. 

Thus, a simple M-Urgency scenario can in¬ 
volve the entities (corresponding RoCoMO 
classes in parentheses): caller ('person'), dis¬ 
patcher ('murgencydispatcher' extended from 
'person') and responder ('murgencyofficer' ex¬ 
tended from 'person'). For instance, because of 
an accident that is an event ('murgencyevent' 
extended from 'event'), a series of activities 
follow such as, the caller calls the police, 
the dispatcher accepts the call, the dispatcher 
assigns ('murgencyassignment' extended from 
'Assign') a responder or officer to the call etc. 
This is only an illustration of how the concepts 
in the core ontology can be extended to model 
concepts specific to an application. 

5 Analysis and Evaluation of Ro¬ 
CoMO 

Bettini et al. Ifl5l and Ye et al. HT8l have specified 
a set of requirements that both context models 
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and ontologies for pervasive computing envi¬ 
ronments should support. We assess RoCoM 
and RoCoMO on the basis of these criteria and 
explain how it addresses them: 

5.1 Representation of static and dynamic 
information 

Contextual information can be static i.e. those 
aspects of a pervasive system that are invariant, 
such as a person's date of birth. However, the 
majority of contextual information is dynamic, 
such as location, with its persistence being 
highly variable. Every element of the RoCoM 
ontology, beginning with the top level classes 
like 'entity', 'activity' and 'event', have their 
contextual information separated into two hier¬ 
archies - static and dynamic. This enables ease 
of distinction between contextual information 
that is persistent over a long period of time 
(static) and that which needs to be updated 
frequently based on its freshness (dynamic). 

5.2 Representation of temporal character¬ 
istics of primitives 

For every primitive such as an entity, activity 
or event, we have defined a time class that 
records properties such as its start time - time 
at which the event/activity started or the en¬ 
tity came into being, end time - time at which 
the event/activity ended or the entity ceased 
to exist (equivalent to the current time if the 
individual still exists), duration or life time of 
an individual (difference of the start time and 
the end time) and recurrence - frequency of 
repetition for an event/activity. The following 
OWL code snippet shows the time class: 

(Class rdf:about="http://mind7.cs.umd.edu:8134/Rover/time#time") 

(/Class) 

(owl :DatatypeProperty rdf:about="http://mind7.cs.umd.edu:8134/ 

Rover / time#startTime") 

(rdfs:domain rdf:resource="http://mind7.cs.umd.edu:8134/Rover/ 
time#time/) 

(rdfs:range rdf:resource="&xsd;dateTime"/) 

(rdfs:subPropertyOf rdf:resource="&owl;topDataProperty"/) 

(/owkDatatypeProperty) 

(owl:DatatypeProperty rdf:about="http://mind7.cs.umd.edu:8134/Rover 
/ time#repetition") 

(rdfs:range:resource="&xsd;string"/ ) 

(rdfs:subPropertyOf rdf:resource="&owl;topDataProperty"/ ) 

( /owkDatatypeProperty ) 

5.3 Timestamping 

Timestamping the dynamic contextual informa¬ 
tion allows the system to determine the fresh¬ 
ness and versioning of the contextual informa¬ 
tion which further enables resolution of con¬ 
flicts and ambiguity. In RoCoMO, the contex¬ 
tual information is timestamped at two levels: 


1) fine-grained level - timestamping every 
dynamic contextual information of an 
individual instance of a primitive to keep 
track of when it was last modified and by 
which entity and 

2) coarse-grained level - timestamping the 
individual instance itself to determine 
when it was modified and by which 
entity. 

The following OWL code snippet shows how 
the hasMood context of an individual xyz of the 
person class in RoCoMO is assigned a value 
happy and is timestamped to determine when 
the contextual information was last updated. 

(Axiom) 

(annotatedTarget rdf:datatype="&xsd;string") happy (/annotatedTarget) 
(rocomo-schema:timeStamp rdf:datatype="&xsd;dateTime") 

2012-09-18T14:00:00 (/ rocomo-schema:timeStamp) 

(annotatedProperty rdf:resource=" &person;hasMood " /) 

(annotatedSource rdf:resource="&person;xyz"/) 

(/Axiom) 

5.4 Machine-interpretable representation of 
contextual information, Efficient context pro¬ 
visioning and Granularity of context 

The model and ontology must employ a 
machine-interpretable representation of context 
to tackle heterogeneity by using semantic anno¬ 
tations. These annotations can enable automatic 
exploitation and transformation of information 
in distributed context sharing scenarios as well 
as automatic context reasoning. They should 
provide efficient access paths to contextual in¬ 
formation and represent it at different levels 
of abstraction. For instance, location of a user 
can be represented at a fine-grained level in 
terms of latitude/longitude and at a coarse¬ 
grained level in terms of the name of a city or 
a building. 

RoCoMO is implemented in OWL2 DL 
which is expressive and allows more versatile 
knowledge representation. In OWL, context can 
be represented as annotated semantics via data 
properties and relationships between different 
elements can be represented via object proper¬ 
ties. It also enables automatic context reason¬ 
ing. Also, OWL represents information hierar¬ 
chically which allows efficient provisioning of 
context and representation at multiple levels of 
abstraction or granularity. 

5.5 Encoding bias/ Comparability 

Contextual information sources constitute a va¬ 
riety of sensors and devices which often use 
different measurement and encoding systems. 
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thus, resulting in a heterogeneous set of values 
describing the same entities. Hence, the context 
model and ontology must not depend on a 
particular symbol-level encoding, such as the 
representation of date in a particular format. It 
should provide means to compare and convert 
values with different scale and encodings. 

To address this, we annotate any measur¬ 
able contextual information with an annotation 
property, called 'scale', defined in a RoCoMO 
schema (This schema enables reification of ev¬ 
ery OWL statement that is part of RoCoMO). 
This removes the model's dependency on any 
particular encoding or measurement unit and 
also facilitates comparison or conversion from 
one unit to another. 

For instance, a person's context can include 
height which can be in feet, meters or any other 
unit. Thus, for person "xyz", we can represent 
height and its measurement unit as: 

(Axiom) 

(annotatedTarget rdf:datatype="&xsd;float") 6.0 (/ annotatedTarget) 

(rocomo-schema:unit rdf:datatype="&xsd;string")feet(/rocomo-schema:unit) 

(annotatedProperty rdf:resource="&person2;height" /) 

(annotatedSource rdf:resource="&person2;xyz" /) 

(/Axiom) 

5.6 Quality of Context (QoC) 

Pervasive computing environments are highly 
dynamic and hence context data is character¬ 
ized by properties such as incompleteness, am¬ 
biguity, uncertainty, inaccuracy, and temporal 
nature. For instance, in some environments, the 
contextual information may be incorrect due 
to a faulty sensor or incomplete due to lack 
of sufficient input. The model and ontology 
should be able to represent this imperfection. 

Several papers including Gray and Salber 
[fl9]| introduced the notion of attaching informa¬ 
tion quality attributes to every piece of sensed 
context. To facilitate this, we have defined 
seven QoC attributes that model imperfection 
in contextual information - accuracy to represent 
correctness, probability or confidence to repre¬ 
sent the certainty of being correct, coverage to 
represent the range, resolution to represent the 
smallest perceivable element, meanError to rep¬ 
resent average error, and recurrence to measure 
repeatability. These annotations are defined in 
the RoCoMO schema and can be attached to the 
appropriate contextual information or a rela¬ 
tionship and can be propagated to applications. 

For instance, a person's context can include 
his/her weight which can be in kgs, pounds or 
any other scale. Also, the weight measure can 


have a mean error attached to it depending on 
the sensitivity of the instrument. Thus, person 
"xyz" having weight 55 Kgs with an average 
error of 1 Kg, can be represented as: 

(Axiom) 

(annotatedTarget rdf:datatype="&xsd;float")55.0(/annotatedTarget) 
(rocomo-schema:scale rdf:datatype="&xsd;string")kgs(/rocomo-schema:scale) 
(rocomo-schemameanError rdf:datatype="&xsd;float") 

1.0 (/ rocomo-schema:meanError) 

(annotatedProperty rdf:resource="&person2;weight"/) 

(annotatedSource rdf:resource="&person2;xyz"/) 

(/Axiom) 

5.7 Provenance and Traceability 

In order to provide adequate control and inter¬ 
pretation of contextual information, the model 
and ontology should provide the means to de¬ 
termine the source of data and transformations 
made to it. In RoCoMO, this is done at a 
coarse-grained level where we store, when the 
contextual information of any instance or an 
individual was created, when was it last modi¬ 
fied, the last modification made to the instance 
and the entity by which it was made. However, 
we are not tracking every single modification 
made to every unique attribute or contextual 
information since this is too cumbersome at 
the modeling level. This can be achieved at 
the system level by logging context history and 
transformations. 

For instance, in our case study, we require the 
temperature of a room along with its source, 
its measurement scale, its time stamp and its 
certainty. Thus, the following OWL snippet rep¬ 
resents an instance of an environment having 
temperature reading of 100 degree Fahrenheit, 
with certainty 0.9, created by a sensor instance 
'sensorl' at 2 pm on 09-18-2013. 

(owl:Namedlndividual rdf: about=" &environment;envreadingl") 

(rdf:type rdf:resource="&environment;environment"/) 

(rdfs:label xml:lang="en")envreadingl (/rdfs:label) 

(environment:temperature rdf:datatype="&xsd;float") 100.0 ( 

/ environment:temperature) 

(entity:createdBy rdf:resource="http://mind7.cs.umd.edu:8134/ 

Rover/ sensor#sensorl"/) 

(/owkNamedlndividual) 

(Axiom) 

(rocomo-schemaprobability rdf:datatype="&xsd;float") 0.9 ( 

/ rocomo-schema:probability) 

(rocomo-schema: timeStamp rdf:datatype =" &xsd;dateTime" ) 

2013-09-18T14:00:00 (/ rocomo-schema:timeStamp) 

(owkannotatedTarget rdf:datatype="&xsd;float") 100.0 (/owl:annotatedTarget) 
(rocomo-schema:scale rdf:datatype="&xsd;string") Fahrenheit 
(/rocomo-schema:scale) 

(owkannotatedSource rdf:resource="&environment;envreadingl"/) 
(owkannotatedProperty rdf:resource="&environment;temperature"/) 

(/owl: Axiom) 

5.8 Heterogeneity and Mobility 

Pervasive computing environments are charac¬ 
terized by distribution, heterogeneity, unpre¬ 
dictability and unreliable communication links. 
Thus, the model and ontology should support 
these requirements and enable the aggregation 


and merging of the data when needed. RoCoM 
is an ontological model and promotes knowl¬ 
edge sharing and reuse across distributed sys¬ 
tems and applications in pervasive comput¬ 
ing environments. Hence, even if the sources 
of context are heterogeneous, distributed and 
partitioned, the contextual information can be 
shared and aggregated across environments. 

5.9 Ease of development 

RoCoMO is developed on the principle of 
Model-Driven Development. The ontology is 
also available publicly. Hence, developers have 
adequate support for development and imple¬ 
mentation. 

5.10 Flexibility, extensibility, applicability, 
generality, evolvability and completeness 

Context models and ontologies should not be 
rigid but flexible and extensible. Thus, they 
should not be restricted to a single domain, 
and should be able to support new and varied 
application domains. They should evolve with 
the applications and their context needs. 

RoCoMO is structured in a modular fashion 
with clear distinction between the Core and 
Application ontologies. Also, as the applica¬ 
tions evolve, more concepts can be added to it. 
Thus, it is easily extensible, flexible and evolv- 
able. It does not target any specific domain in 
pervasive computing and is intended to be gen¬ 
eral and applicable across several applications 
and domains. As a result, we do not claim that 
the ontology is complete. 

5.11 Interoperability 

Since several existing projects use standard up¬ 
per ontologies, every generic ontology should 
be interoperable i.e. its term definitions must 
be consistent with other standard, generic and 
consensus ontologies such as SOUPA H3fl. This 
also enables reuse of domain knowledge |8|. 

We have designed RoCoMO to be inter¬ 
operable with other ontologies, for instance 
SOUPA El, via the equivalentClass and equiva- 
lentProperty OWL statements. The example be¬ 
low shows that the RoCoMO person class is 
defined equivalent to the person class in SOUPA 
and the dateofbirth property is defined equiva¬ 
lent to birthDate property in SOUPA. 

(Class rdf:about="&person;person") 


(rdfs:label xml:lang="en") person (/rdfs:label) 

(equivalentClass rdf:resource="http://pervasive.semanticweb.org/ont/2004 
/ 06 /person#person" /) 

(rdfs:subClassOf rdf:resource="http://mind7.cs.umd.edu:8134/Rover/ 
physicalentity#physicalEntity " /) 

(/Class) 

(DataProperty rdf:about="&person;dateofbirth") 

(rdfs:label xml:lang="en") dateofbirth(rdfs:label) 

(rdfs:subClassOf rdf:resource="&person;personalinfo"/) 

(equivalentProperty rdf:resource="http://pervasive.semanticweb.org/ont/ 

2004/06/person#birthDate"/) 

(/ DataProperty) 

5.12 Clarity, Coherence, Redundancy and 
Orthogonality 

The concepts in RoCoMO are unique, unam¬ 
biguous, independent and consistent. 

5.13 Security and Privacy 

These are implemented in RoCoM using Role 
Based Access Control (RBAC) for groups and 
members. A group is an instance of type 'ac- 
cessgroup' class. This class has object properties 
like 'groupmember' which includes the entities 
like users or devices that can be assigned to an 
instance of the group. The 'accessgroup' class 
also has an object property called 'privileges' 
which defines the permissions that the group 
can have. These permissions can be in the form 
of an 'activity' that the group is allowed to 
perform. Every entity can belong to multiple 
access groups while each access group can have 
multiple entities and privileges. This form of 
access control, obtained by assigning users to 
groups and granting privileges to groups rather 
than individual users, reduces the number of 
associations involved that need to be managed. 
Hence, it is easier to define security policies 
around this framework. 

6 Modeling the Fire Incident Case 
Study using RoCoMO 

In this section, we revisit the Fire Incident 
case study from Section [2] and illustrate how 
RoCoMO can be used to model it. Figure [3] 
shows a graphical representation of the situ¬ 
ation modeled in RoCoMO. At time t 0 , the 
Fire Incident Event triggers the situation that 
follows and sets the Goal Evacuate. This goal 
can be subdivided into smaller sub-goals which 
can be performed by one or more activities. 
Entity Responderl performs the Activity Get 
updated temperature readings, at time ti, to get 
the context information of room Rooml23 - the 
updated temperature readings from the tem¬ 
perature sensors TempSensorl and Temp Sensor 2. 
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Fig. 3: Fire Incident Case Study modeled using RoCoMO 


The Goal for this activity is Determine time left 
for evacuation. Since the information is times- 
tamped, the system can refresh it periodically 
based on its freshness and this resolves any 
ambiguity. 

The contextual information also has a prob¬ 
ability measure attached to it. As shown in the 
figure, the probability of temperature reading, 
from TempSensorl, being correct is 0.1 which 
means it is highly unreliable and that the sensor 
could be faulty. This is evident by the fact that 
it shows a reading of 10 deg Fahrenheit while 
the other sensor shows a reading of 150 deg 
Fahrenheit. Also, the contextual information 
has source or provenance information attached 
to it and so this determines which reading came 
from which sensor. Based on the temperature 
reading and its encoding (Fahrenheit in this 
case), the system can calculate how much time 
it will take till the temperature reaches the 
value at which the building bursts into flames. 
This is the amount of time that the responders 
have for evacuation. 

Simultaneously, another entity Responded is 
performing the activity Access building floormaps 
with the Goal - Determine exit routes for evacu¬ 
ation. Since the responders belong to the Ac- 
cessGroup responders, the system checks their 
privileges (which are inherited from the 're¬ 


sponders' accessgroup) and grants access to 
the temperature readings from the sensor and 
building floor plans. Once these two activities 
have achieved their goals, both the responders 
start the activity Evacuate people, at time t 2 , and 
achieve the goal set by the event. 

7 Conclusion and Future Work 

In this paper, we described a generic, flexible 
and extensible ontology called Rover Context 
Model Ontology(RoCoMO) and illustrated its 
benefits for context and situation modeling in 
pervasive computing environments, via a prac¬ 
tical case study. We highlighted several short¬ 
comings of contemporary context models and 
ontologies and explained how RoCoMO ad¬ 
dresses them. We also established the utility of 
its capabilities by evaluating it against several 
criteria that ontologies for context and situa¬ 
tion modeling should possess. Our next step 
is to develop a GUI to allow users to browse 
and explore the RoCoM ontologies, and further 
extend and modify them. An API for working 
with the ontology will also be available. Our 
aim is to encourage users to build applications 
and systems using this ontology so that they 
can be used in both in an isolated manner or 
integrated with Rover II. 
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